This invention relates to servers for computer network systems. More particularly, this invention relates to a timeout mechanism for selectively timing out client-server sessions on the server.
A computer network system has one or more host network servers connected to serve data to one or more client computers over a network. In a typical exchange, a client sends a request for data and/or services to a server over the network. The server processes the request and returns a response.
The server runs an operating system to handle communication interaction with client-based applications. The server operating system establishes the connection between the server and the client and allocates resources to handle requests from the client. When a client first connects to the server, the server operating system creates a new session for the client. The sessions are cached according to their ID in a main session table. All requests and responses are handled through the client session. When the client is finished submitting requests to the server, the session for that client is terminated.
One way to terminate a session is through session timeout. A xe2x80x9csession timeoutxe2x80x9d occurs when no requests for a particular session are received at the server for a specified period of time. Each session can potentially have its own timeout period. Usually, the session timeout is defined in time units that are more appropriate for humans, rather than a micro scale suitable for fast executing machines. For example, it is common to set a session timeout to five minutes, rather than 303,142,489 microseconds. Furthermore, timeout accuracy need not be precise. If a timeout period for a session is set to five minutes and that session times out at five minutes and twenty seconds, the extra twenty second xe2x80x9cerrorxe2x80x9d is typically acceptable as being within the timeout parameters.
Session timeout management is particularly useful in the context of the Internet. It is not uncommon for a client to request certain data and/or services, and then browse to another site without expressly terminating its current session. The Web server starts a session for the client, and that session remains active until it is timed out. For popular Web sites, many sessions (e.g., hundreds to thousands) may be simultaneously opened to serve the clients. When clients leave without disconnecting, the Web server is often left with many open sessions that never again receive active requests. Unused open sessions unnecessarily consume server resources that could better be allocated to serving new clients. To improve performance, the Web server times out client sessions when no requests have been received for a predefined time period.
When designing server applications, one important consideration is scalability. Scalability implies that more resources yield more performance. One primary limitation on performance, and hence on scalability, is lock contention. xe2x80x9cLock contentionxe2x80x9d is a condition in which multiple server threads try to access the same resource simultaneously, thereby locking each other out of the resource. Adding more resources, such as more processors, does not alleviate the lock contention problem.
Lock contention is particularly visible in session timeout management. When a new session is added, the main session table is locked to prevent other threads from disrupting the table""s composition while the session is being added. When a session times out, the table is locked again to allow removal of the session. Locking during insertion and removal of sessions is unavoidable, and unfortunately impedes processing and hampers performance.
One conventional solution is to multiplex access to the session table based on an arbitrary ID. The session table is partitioned into several tables according to session ID (e.g., using harsh partitioning) and locks are asserted separately on a partition basis. Even with this multiplexing, there remains a need for an improved mechanism to time out sessions in a way that does not add any additional lock contention to the main session table.
Session table lockout is just one example of lock contention problem. Essentially, the lock contention problem is evident anytime multiple threads are accessing the same data structure.
This invention is directed to an improved method for managing sessions, and other resources, in a manner that minimizes lock contention.
This invention concerns a session timeout mechanism for managing sessions in a manner that minimizes lock contention. As a result, the session timeout mechanism is scalable.
According to one implementation, a network server system has a session manager to manage client-server sessions. When a client connects to the server, the session manager initiates a corresponding session to facilitate communication between the server and the client. The session manager places the session in a session table. The session has an associated timeout period dictating when the session is to be terminated in the event that no further requests are received from the client.
The session manager includes a session timeout mechanism to selectively timeout client-server sessions in a manner that minimizes lock contention on the main session table. The session timeout mechanism has multiple timeout buckets to hold corresponding groups of sessions according to the expected timeout moment. Sessions located in different ones of the timeout buckets are set to timeout at different times.
The session manager also has a session timeout clock that is incremented every predetermined time unit (e.g., every minute). The session timeout clock maintains a pointer (e.g., index) to one of the timeout buckets and advances that pointer with each clock increment. The session timeout clock advances the pointer through all of the timeout buckets, one bucket at a time. The session timeout clock advances the pointer repeatedly through all the buckets. The cycle time for the session timeout clock to reference every timeout bucket is equal to the incremental time unit multiplied by the number of buckets.
When the timeout clock references a particular bucket, the sessions in that bucket are analyzed for possible timeout. Sessions whose timeout period has run without receiving any new requests are timed out and removed from the bucket.
A new session (or one that recently received a request and is restarting its timeout period) is inserted into a timeout bucket that is one or more buckets ahead of the clock pointer, depending upon the session""s timeout period. For instance, if the incremental clock interval is one minute and the session""s timeout period is five minutes, the session is placed in the fifth timeout bucket ahead of the currently referenced timeout bucket. As the pointer is eventually advanced to the fifth timeout bucket (now the current bucket), a time period of at least five minutes will have elapsed. If the session has received no new requests in the interim, the session manager times out the session and removes it from the bucket.